Building Evolutionary Architectures: Support Constant Change by Neal Ford & Rebecca Parsons & Patrick Kua

Author:Neal Ford & Rebecca Parsons & Patrick Kua [Ford, Neal]
Language: eng
Format: azw3, epub
Publisher: O'Reilly Media
Published: 2017-09-18T04:00:00+00:00

Figure 5-5. The transitional state, where the service supports both versions of routing

As seen in Figure 5-5, the service can support both APIs as long as developers need the old routing service. In essence, the application now supports two versions of routing information.

When the old service is no longer needed, the routing service developers can remove the old table and the trigger, as shown in Figure 5-6.

Figure 5-6. The ending state of the routing tables

In Figure 5-6, all services have migrated to the new routing capability, allowing the old service to be removed. This matches the workflow shown in Figure 5-2.

The database can evolve right alongside the architecture as long as developers apply proper engineering practices such as continuous integration, source control, and so on. This ability to easily change the database schema is critical: a database represents an abstraction based on the real world, which can change unexpectedly. While data abstractions resist change better than behavior, they must still evolve. Architects must treat data as a primary concern when building an evolutionary architecture.

Refactoring databases is an important skill and craft for DBAs and developers to hone. Data is fundamental to many applications. To build evolvable systems, developers and DBAs must embrace effective data practices alongside other modern engineering practices.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.